Computer networks have enhanced our ability to communicate and access information by allowing one computer or device to communicate over a network with another computing system using electronic messages. Typical communications between computing systems rely on a client-server relationship, where the client sends a request for services offered by a server and the server performs the desired function. Of course, the communications are governed by various protocols and other requirements such as authentication, authorization, security concerns, etc.
One common protocol used in the client-server relationship provides a series of restrictions on how messages are received and processed. Such protocols are commonly referred to as “request-response” type protocols, which include such specifications as the hypertext transfer protocol (HTTP) series (including standard HTTP, secure HTTP, reliable messaging HTTP, etc.), the file transfer protocol (FTP) series (including standard FTP, secure FTP, etc.), simple network management protocol (SNMP), and others. As the name implies, these protocols in general rely on the client sending a “request” message and the server responding on the same channel or port with a “response”, even if the response is a simple acknowledgment of the receipt of the request.
In recent years, servers supporting such request-response protocols have evolved from monolithic entities into groups of specialized modules where the functionality of the server is broken up into specialized pieces that can be removed, replaced with new ones, and, in general, provide the capability of extending the server's functionality. In order to make this possible, the servers have exposed a set of application program interfaces (APIs), which provide access to various server data structures for allowing the manipulation of a client request and the server's response thereto. In order to facilitate this modular model of operation, servers have a number of stages (e.g., an authentication stage to authenticate the user, a logging stage to log results, etc.) where data may be read or altered. Modules can be developed and installed on the server which subscribe to particular stages on the server to have their functionality executed in one or more of these stages. Using this model, server functionality is easily extendible, flexible, scalable, and available, thus providing for a more robust service as desired by developers and others using the server resources.
As new modules are developed for a server, it becomes critical to properly test and troubleshoot the modules to find errors and tune performance—both during development and after deployment. A large challenge in testing and troubleshooting modules in servers, however, comes from the fact that the data which the server maintains, manipulates, and provides can be altered by any module during various stages in which they are executed. Since multiple modules can execute during the same stage (e.g., when a user is authenticated), it is difficult—if not impossible—to determine which particular module is at fault when an error occurs or which module might be responsible for a particular change in data. In some cases, it is even difficult to determine the stage in which a particular error or data change may have occurred.
It is also cumbersome and problematic in a typical development and debugging cycle to develop module-specific debug code, compile a module with debugging code or statements, deploy the altered module onto the server, and run a test. This code-compile-test-debug cycle may take an inordinate amount of effort and time, since in order to monitor certain behavior in different stages using various modules each scenario must independently be designed for and implemented. This typical method of debugging may also be problematic in that a module, which has been altered and compiled with inserted debugging code, often behaves differently than an unadulterated module. Accordingly, a particular error or result may not manifest itself or otherwise occur during execution of a module with such debug code—as opposed to a module that had not been altered.